In the related art, when entering a network, data accesses a large number of value-added service devices, such as antivirus devices, acceleration devices, firewall devices and Network Address Translation (NAT) devices. Undifferentiated traffic must pass through these service devices simultaneously, thus causing an unnecessary load on these devices, limiting optimization of service resources, and hindering rapid changes in service configurations due to complex configurations.
In view of these problems, a mode of service chain which is called Service Function Chain (SFC) is proposed at present. That is, all services are integrated to form a virtual service overlay having its own service topology that is decoupled from an underlay network and no longer restricted by a structure of the underlay network. A structure diagram of the SFC is shown in FIG. 1. FIG. 1 is a structure diagram of an SFC in the related art. A service through which traffic is to pass is determined by the SFC. A Service Function Path Identifier (SFPID) is added to each SFC and packets are classified into different levels by SFC. Different SFCs are allocated to the traffic at different levels (by an entrance classifying device). A forwarding device forwards a packet according to an identifier of an SFC. As a result, different service chain processions are implemented for different traffic to meet differentiated requirements.
The current SFC processing is shown in FIG. 1. An SF refers to a service function. A classifier is used for classifying packets and adding an SFC header to a packet. The packet carries a Service Function Path Identifier (SFPID) of the packet. An SFF refers to a service function forwarder. According to the SFPID carried in the packet, a corresponding SF or SFF is selected for packet forwarding. That is, for the packet received by the classifier or the SFF, the SFF forwards the packet to an SF that belongs to a service function path according to the SFPID of the packet. For the packet received by the SF, the SFF selects a next hop according to the SFPID of the packet and then transmits the packet to a next SFF according to an address of the next hop.
The Network Virtualization Overlays 3 (NVO3) working group of the Internet Engineering Task Force (IETF) proposes a Network Virtualization Edge (NVE) function. Through this function, a packet is encapsulated, enabled to access an overlay network and then forwarded. When traffic enters the overlay network, the packet is encapsulated and allocated an outer layer address of the overlay network by an NVE device. After reaching a destination NVE, the packet is first de-encapsulated and then transmitted to a destination host. When service chain processing is performed in the overlay network, it is needed to determine service chains to be used in different virtual networks, and a mapping between various virtual networks in the overlay network and various service chains is needed.
When an SFC function is added to an existing overlay network, an original NVE may not know about the SFC function, so it is needed to use software to enable a Virtual switch (Vswitch) of a host to support the SFC function. At this time, an NVE and an SFF may be physically separated from each other, so the NVE may not know about a next hop of the SFC and a packet is directly forwarded to an NVE where a destination host is located via a tunnel according to a destination address of the packet, failing to ensure that the packet is transmitted to a correct next-hop SFF via a tunnel of the overlay network for SF processing, and thus resulting in a wrong path of an entire service function chain.
No effective solution has been provided to solve a problem of failing to transmit, via a tunnel of an overlay network, a packet to a correct next-hop SFF for SF processing in the related art.